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Summary of claimed subject matter 

The references to the specification contained in the summary below refer by page and 
line to the Substitute Specification filed with the Preliminary Amendment filed on April 10, 
2002. The particular sections of the specification and drawings referenced below are illustrative 
and representative, but do not identify all of the descriptive material that corresponds to any 
element of the appealed claims. 

Each of the independent claims 1, 8 and 16 defines an interface program /"Fig. I at 113; 
page 2, lines 18 -23; Fig. 3 and Section 3. DSE Execution at pages 22-35 ] that receives requests 
for information [Fig, 2 at 322; page 2, lines 17-23; see ; page 14, line 26 to page 15, via an 
application program interface />^/^e J, lines 12-18; page 14, lines 12-16] from an application 
program [Fig. 1 at 117, 130, page 5, lines 22-27] . The request from the application program 
identifies a particular resource [page 2, line 1 7; see Section 3.3 Input Manager at pages 24-26]. 
The interface program then retrieves a particular service description for the particular resource 
identified by the application program [page 3, lines 12-16, and see Section 2. Service Definition, 
at pages 15-22 for details of the service descriptions]. The interface program then processes 
input data obtained from the requesting application program in accordance with an input 
information specification in the particular service description to produce a request message [Fig. 
2 at 324-333; page 3, lines 6-10; see Section 3. DSE Execution at pages 22-3 5 for details]. The 
interface program next transmits the resulting request message to an Internet address that is 
contained in the particular service description previously retrieved /"F?^. 2 at 335; page 2, lines 
14-24; The Internet address is expressed as a unique URN: see Section 2.1.1.1 ]. Finally, the 
interface program processes the raw response data supplied by the particular resource in response 
to the transmitted request message to create a reformatted response which is routed to the 
requesting application program [Fig. 2 at 343-361 ]. 

Dependent claims 6-7 and 17-18 argued separately in connection with Ground 4 below 
state that service descriptions stored in the service description database further include test 
information and security information /"i**!^. 2, 324, 331 and 333; page 2. line 30 to page 3, line 5; 
page 9,item 8; page 12, lines 3-7 and 20-28]. 
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Grounds of rejection to be reviewed on appeal 

Ground 1 (Claims 1-18): Claims 1-18 were rejected under 35 U.S. C. §101 as being 
directed to non-statutory subject matter; that is, "as not being tangible." The Examiner contends 
that "an 'application program' is not limited to a tangible embodiment since the application 
program requires use of hardware to accomplish operation steps" and that "Claims 1-18 do 
not include any hardware such as computer, therefore, claims 1-18 are non-statutory as not 
being tangible." There is no basis in law or fact for the rejection under §101. 

Ground 2 (Claims 1-18 ): The Examiner contends that Meltzer discloses the all of the 
features of appellants' invention as set forth in independent claims 1 and 12 except for 
"producing an information request message that includes input information and transmitting that 
information request message to the Internet address included in a service description," and 
likewise for independent claim 8, the Examiner contends that Meltzer discloses all of the claimed 
features except for "transmitting said reformatted request to the Internet resource address and 
receiving a raw response via the Internet." As discussed below, there are numerous other 
differences between the subject matter claimed by appellants and the system described by 
Meltzer. As a consequence, the § 103(a) rejections based on Meltzer should be reversed. 

Ground 3 (Claims 1-18): The Examiner contends that it would have been obvious to 
modify the Meltzer system in accordance with the teachings of Call to supply those elements 
which the Examiner concedes Meltzer does not teach. As discussed below, there is no teaching 
in either Meltzer or Call that would suggest why or how such a modification might be made, and 
the Examiner has identified no motivation or need to make such a modification. The § 103(a) 
rejection of claims 1-18 should be reversed for this additional reason. 

Ground 4 (Claims 6-7 and 17-18): The Examiner has rejected dependent claims 6-7 and 
17-18 under §103(a) relying on Meltzer, Call and Walker. The Examiner acknowledges that 
neither Meltzer nor Call disclose storing test information and security information in the service description 
for each resource and then using that information to perform automated testing and authorization functions; 
however, the Examiner asserts that these missing functions are taught by Walker. In fact. Walker discloses 
nothing that could be comlnned with the teachings of Meltzer and Call to yield the claimed combination. 
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Argument 

The four grounds of rejection presented for review are discussed individually below. 

Ground 1: The SlOl non statutory subject matter rejection 

The rejection of claims 1-18 as being directed to non-statutory subject matter is contrary 
to established law. Appellants* claims define statutory metfiods and apparatus for performing 
computer-related processes that are limited to practical applications in the technological arts and 
produce concrete, tangible and useful results: for example, permitting executing application 
programs to obtain and process information obtained via the Internet from identified remote 
resources using a standard API that serves such application programs. 

That is all that section 101 requires. As summarized in §2106, part IV(A), of the Manual 
of Patent Examining Procedure: 

"As the Supreme Court has held, Congress chose the expansive language of 35 
U.S.C. 101 so as to include "anything under the sun that is made by man." Diamond v. 
Chakrabarty, 447 U.S. 303, 308-09, 206 USPQ 193, 197 (1980). Accordingly, section 
101 of title 35, United States Code, provides : Whoever invents or discovers any new and 
useful process, machine, manufacture, or composition of matter, or any new and useful 
improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. In Chakrabarty, 447 U.S. at 308-309, 206 USPQ at 197, the 
court stated: In choosing such expansive terms as "manufacture" and "composition of 
matter," modified by the comprehensive "any," Congress plainly contemplated that the 
patent laws would be given wide scope. 

* * * 

"This perspective has been embraced by the Federal Circuit: The plain and 
unambiguous meaning of section 101 is that any new and useful process, machine, 
manufacture, or composition of matter, or any new and useful improvement thereof, may 
be patented if it meets the requirements for patentability set forth in Title 35, such as 
those found in sections 102, 103, and 112. The use of the expansive term "any" in section 
101 represents Congress's intent not to place any restrictions on the subject matter for 
which a patent may be obtained beyond those specifically recited in section 101 and the 
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Other parts of Title 35. * * * Thus, it is improper to read into section 101 limitations as 
to the subject matter that may be patented where the legislative history does not indicate 
that Congress clearly intended such limitations. 33 F.3dat 1542, 31 USPQ2d at 
1556." 

The Examiner has neither explained, nor cited any authority for, the conclusion that 
appellants' claims are non-statutory simply because they refer to "an application program [that] 
requires the use of hardware to accomplish operation steps." 

Besides having no support in the law, the Examiner's conclusion that application 
programs are "not tangible" has no basis in fact. The "application programs" specified in 
appellants' claims are real -life functional entities that issue service requests, provide input 
information to the service interface program when requested, and receive output information 
from the interface program. While it is true, as the Examiner suggests, that "the application 
program requires the use of hardware to accomplish operation steps," that does not mean that 
applications programs are not real things that exist in the physical world (machine readable 
instructions stored in a physical media) and that perform functions that yield concrete, practical, 
useful results. 

The rejection of claims 1-18 as being directed to non-statutory subject matter is contrary 
to well established law and should be reversed. 
Gronind 2: The obvioiisness rejectians based on Mdizer 

The Examiner contends that Meltzer discloses the all of the features of appellants' 
invention as set forth in appellants' claims except for the features discussed below in connection 
with Grounds 3 and 4 which the Examiner acknowledges are not taught by Meltzer There are, 
however, other significant differences between appellants' claimed invention and the system 
described by Meltzer. These additional differences are expressly stated in claim limitations 
which are not taught or suggested by Meltzer as contended by the Examiner. 

As stated §2143.03 of the Manual of Patent Examining Procedure: 

"To tstahlishprima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 
USPQ 580(CCPA 1974). "All words in a claim must be considered in judging the 
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patentability of that claim against the prior art." In re Wilson, 424 F. 2d 1382, 1385, 165 
USPQ 494, 496 (CCPA 1970). If an independent claim is nonobvious under 35 U.S.C. 
103, then any claim depending therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988)." 

As an introduction, the following brief illustrated comparison between the claimed 
subject matter and the Meltzer system will be presented to illuminate these differences. 



rvice 
description 





Particular 




service 


■ — p 


description 



Application 
Program 



Request for 
information 



input info 

from 
application 
program 



Reformatted 
response 




Applicants' claimed invention 

As illustrated in the simplified diagram seen above, the appealed claims describe a 
service interface program that receives a request for information via an application program 
interface (API) from an application program. The request issued by the application program 
specifies a particular resource. The interface program then retrieves a particular service 
description that corresponds to that particular resource from a database. The interface program 
then processes input data that conforms to the service description from the requesting application 
program to produce a request message. The interface program transmits the resulting request 
message to an Internet address that is contained in the particular service description previously 
retrieved. When the remote resource returns raw response data, the interface program creates a 
reformatted response which is routed to the requesting application program. 
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Transaction 
Processing 



Meltzer 6.542.912 

The cited Meltzer system is illustrated above. Meltzer publishes service descriptions 
(called "business interface definitions" or "BIDs") in an accessible repository. Each BID 
describes a service provided by a resource and describes the format of the XML business 
documents that are exchanged when the service is used. The node interface that receives an 
input document acts as the front end for transaction processing the input XML business 
document. It parses and processes the received documetn in accordance with the protocol 
specification contained in the BID and, after the transaction is processed, returns a standard form 
output business document via the Internet to the requesting trading partner. See generally, 
Meltzer* s Summary of the Invention at col. 2, line 45 through col. 4, line 3. 

Some of the differences between appellants' invention as claimed and the Meltzer system 
may be briefly summarized as follows: 

First, Appellants' claimed invention employs a "client side" interface program that sends 
request messages via the Internet, whereas Meltzer's "server-side" inter&ce receives request 
messages (XML input documents) from the Internet. Appellants' claims state that the interface 
program transmits an information request message via the Internet to the Internet address 
included in the particular service description. The Examiner concedes that Meltzer does not 
describe an interface program that produces a request message in the manner claimed and 
concedes that Meltzer does not transmit such a request message via the Internet to an Internet 
address contained in a service description. The Examiner' s proposed modification in view of 
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Call to supply this deficiency is discussed below in connection with Ground 3 . But, contrary to 
the Examiner's contention, Meltzer is also different from the claimed subject matter in the 
following additional ways: 

Appellants' client-side interface program performs a sequence of information exchanges 
with the requesting application program via an application program interface that are not 
performed by Meltzer's server side interface. First, appellants' interface program receives a 
request for a particular service from the requesting application program via an application 
program interface. Meltzer's interface which is located at the server side and provides "front- 
end" processing for incoming XML documents does employ an API for receiving service 
requests from requesting application programs. 

Appellants' interface program responds to information requests received via this API by 
performing a sequence of operations: (a) it retrieves a service description corresponding to the 
particular resource designated by the service description; (b) it obtains and processes input 
information from the requesting application program in accordance with an input processing 
specification contained in the service description; (c) it then forms and transmits the output 
request message which is transmitted via the Internet to the Internet address specified in the 
particular service description; and (d) it then processes the raw data received from the particular 
resource in accordance with an output specification from the particular service description and 
returns the reformatted output information to the requesting application program. 
Meltzer doesn't work that way. 

Meltzer receives incoming requests in the form of standard XML business documents 
received via the Internet, and does not receive service requests from an executing application 
program via an API. 

Meltzer's interface parses and processes the incoming XML input documents which 
contain all of the input information and does not first receive an information request that 
specifies a service, obtain a service description for that service, and then obtain input information 
from the requesting application via an API that conforms to the input specification contained in 
the service description. 

Since Meltzer's interface operates as the front end to transaction processing, it does not 
need to send a request to a remote transaction service via the Internet and then process the output 

data returned from that remote service, since it is itself the transaction service. 
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Accordingly, it is submitted that there subject matter set forth in appellants' claims differs 
in several respects from the Meltzer system that go beyond the fact that Meltzer's server side 
interface does not send request messages via the Internet. 

As discussed in detail below, the passages cited by the Examiner do not support the 
conclusions expressed in the outstanding Office Action. 

The Examiner suggests that Meltzer teaches an interface program that receives a service 
request identifying a particular resource from an executing application program and then obtains 
a service description corresponding to the particular resource, citing col. 19, lines 16-40 of 
Meltzer. However that cited passage describes the process of building a BID by gathering the 
data it stores, and nothing in that cited passage says anything about an interface program that 
receives a service request from an application program that identities a resource and the retrieves 
a corresponding service description. The Meltzer program that is used to build a GID described 
in the cited passage of col. 19 fails to perform any of the recited functions which the claimed 
interface program is required to perform by the claims. 

The Examiner next suggests that, at col. 3, lines 4-58, Meltzer teaches an interface 
program that obtains input information from an executing application program that conforms to 
the input specification contained in a retrieved particular service description. While Meltzer 
does describe a remote services program that receives input information (one or more standard 
XML input documents) via the Internet from a remote trading partner, Meltzer's front end 
interface does not the sequence of operations claimed. Meltzer receives the input document, 
determines its type, and then processes the input document using routines that are established to 
conform to the service description. Nowhere does Meltzer suggest that an executing application 
program first issues a service request that identifies a particular resource, and that an interface 
program then processes that service request by retrieving a service description from a database 
and thereafter obtains input information from the requesting application that conforms to the 
input processing specification contained in the received service description. 

The Examiner cites the passage at col. 24, line 56 to col. 25 line 5 of Meltzer which 
describes how the service provider receives a standard input document via the Internet, parses it 
to identify the service type requested, translates the incoming document into a native format for 
processing by transaction processing routines registered for handling incoming documents of that 

type, and then returns the resulting output data via the Internet as a standard XML output 
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document. This passage does not describe an interface program that first receives a service 
request from an executing application that identifies a particular resource, then retrieves a service 
description, then obtains input information from the requesting application, and then creates a 
request message that is sent via the Internet to the Internet address of the particular resource 
contained in the retrieved service description, as required by all of the claims. 

It is accordingly submitted the Examiner has failed to establish prima fascia obviousness 
of the claimed invention because several claim limitations are neither taught nor suggested by the 
Meltzer as contended by the Examiner. 

Ground 3: The obviousness rejections based on 
the proposed modification of Mellzer in view of Call 

The Examiner contends that it would have been obvious to modify the Meltzer system in 
accordance with the teachings of Call to supply the elements which the Examiner concedes 
Meltzer does not teach. As discussed below, there is no teaching in either Meltzer or Call that 
would suggest why or how such a modification might be made, and the Examiner has identified 
no motivation or need to make such a modification. 

As stated §2142 of the Manual of Patent Examining Procedure: 

"The legal concept of prima facie obviousness is a procedural tool of 

examination which applies broadly to all arts. 

* *'* 

The examiner bears the initial burden of factually supporting any prima 

facie conclusion of obviousness. If the examiner does not produce a prima facie 

case, the applicant is under no obligation to submit evidence of nonobviousness. 

*** 

To establish a prima facie case of obviousness, three basic criteria must be 
met. First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must 
be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations." 

10 



PAGE 11/22* RCVD AT 10130120069:02:17 PM [Eastern Standard Time]* 8VR:USPT0-EFXRF-1I9 * DNI8:2738300*CSID:1-508-629-6540 CCALL* DURATION (mm-ss):07-32 



To: USPTO Page 1 2 of 22 



2006-10-31 02:02:30 (GMT) 



1 -508-629-6540 CCALL From: Charles Call 



And as further stated §2143,01 of the Manual of Patent Examining Procedure: 

"If the proposed modification or combination of the prior art would 
change the principle of operation of the prior art invention being modified, then 
the teachings of the references are not sufficient to render the claims prima facie 
obvious. /« re Ratti. 270 F.2d 810, 123 USPQ 349 (CCPA 1959)" 

The Examiner acknowledges that Meltzer does not describe an interface program that 
produces a request message in the manner claimed nor does Meltzer transmit such a request 
message via the Internet to an Internet address contained in the service description. Instead, 
Meltzer identifies the requested service from the content of the received standard input document 
and then processes the input document using locally executed routines for handling input 
documents of the type received. 

But the Examiner suggests that Meltzer's mechanism could be modified in some 
unspecified way in view of the teachings of the Call Patent. But the Examiner does not explain 
how one skilled in the art would be led to modify the Meltzer system in view of its teachings, nor 
does the Examiner provide a reason why one skilled in the art would attempt to make such a 
modification. In rejecting independent claim 1, the Examiner states: 

"However, Meltzer does not explicitly disclose producing an information request 
message that includes said input information, and transmitting said information request 
message to the Internet address included in said particular resource. In the same field of 
endeavor. Call discloses receiving Internet request messages containing all or part of a 
universal product code and returning the Internet address at which information about the 
identified product or the manufacturer of that product may be obtained via Internet 
(Abstract and col. 5, lines 29-42). Since Call discloses a method for communicating 
between manufacturer and resellers and consumers, which is similar to commercial 
transactions between customers and suppliers of Meltzer, it would have been obvious to one 
of ordinary skill in the art at the time the invention was made to combine the 
teachings of Call and Meltzer to include transmitting said reformatted request to 
the Internet resource address and receiving a raw response via the Internet. Call's system 
enables the retrieval of information about products from the source of the manufacturer and 

1 1 
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also provide low cost, worldwide and bi-directional communication between 
manufacturer and consumers." 

But the fact that Call and Meltzer are "in the same field of endeavor," and the fact that 
both deal with communications between customers and suppliers, in no way suggest that Meltzer 
should be modified in view of Call so that Meltzer's interface program would somehow transmit 
request messages via the Internet in the manner claimed instead of performing as Meltzer 
describes. Meltzer's interface, being located at the provider's server and having received in 
input XML business document, has all the information it needs from the requestor and doesn't 
need to issue any sort of further request for more information. Even if it did have such a need, 
there is no reason to believe that Call's method for obtaining product information via the Internet 
given a Universal Product Code value could somehow make a useful contribution to Meltzer's 
system. Meltzer describes a system in which all of the components, including the interface 
program that operates as the front end to the transaction processing, operate in an integrated way 
to achieve a desired result. The substantial modification that the Examiner proposes would 
appear to render the Meltzer system inoperative for its intended purpose. 

The rejection of claims 1-5 and 8-16 based on the proposed combination of Meltzer and 
the Call Patent should accordingly be reversed for the further reason that because there is nothing 
in the Call Patent that would suggest a modification of the Meltzer trading system that would 
yield the claimed interface program. 

Ground 4: The obviousness rejections based on the 
proposedmodificadon of Meltzer and C all iti vi< ^w of Walker 

The Examiner further rejected claims 6-7 and 17-18 as being unpatentable over Meltzer 
and the Call Patent as applied in the manner discussed above with respect to Grounds 2 and 3, 
and further in view of Walker. These dependent claims further recite that the service description 
contains additional information that can be used to verify that the system is operating correctly 
and that requests are being issued from authorized sources before those requests are satisfied. 
The Examiner concedes that Meltzer and the Call Patent do not describe these additional 
features, but cites Walker in support of the contention that these additional features would have 
been obvious. These rejections should also be reversed. 

12 
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With respect to claims 6 and 17 which claim storing a fixed input value and a fixed 
output value in the service description to test the system, the Examiner cites the teaching of 
Walker in which a test is performed to see if a purchase offer is accepted or rejected. It is not 
clear how this test might be incorporated into the Meltzer system, but if it were it would plainly 
not meet the limitations stated in claims 6 and 7. Walker does not teach storing fixed input and 
output values in a service description, sending the input value in a request message, and 
comparing the resulting output value with the stored output value as claimed. The rejection of 
claims 6 and 17 based on Walker is accordingly erroneous because neither Walker does not 
supply any teaching of the elements recited by claims 6 and 17 that is acknowledged to be 
missing from Meltzer and Call. 

With respect to claims 7 and 18 based on Walker's teaching of encrypted transactions for 
security, it is submitted that one skilled in the art might indeed use a variety of well known 
security techniques such as encrypted transmissions to improve the security of Meltzer's 
transactions, but that does not make it obvious to modify Meltzer by placing security information 
in a service description to insure that requests are not responded to if they are found to come 
from an unauthorized source. There is thus nothing in the Walker patent that suggests the 
subject matter specifically claimed in claims 7 and 18. 

Conclusion 

The final rejection of claims 1-18 should be reversed. 

The Examiner's rejection of the claims as being directed to non-statutory subject matter 
is contrary to law since the claims are clearly directed to methods and apparatus that provide 
concrete useful results. The rejection of the claims for obviousness must also be rejected since 
numerous elements expressly recited by the rejected claims are nowhere disclosed or suggested 
by any of the cited references, and because the Examiner has failed to identify any reason why 
one skilled in the art would attempt to modify Meltzer in view of Call. 

Oaims appendix 

An appendix containing a copy of claims 1-18 involved in the appeal is attached. 

Evidence appendix 

No other evidence w^as submitted or is being relied upon by appellants. 
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Related proceedings appendix 

There are no related proceedings. 

Respectfully submitted. 




Dated: October 30, 2006 Charles G. Call, Reg. 20,406 
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Charles G. Call, Reg. No. 20,406 

USPTO Customer No. 021253 
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CX AIMS APPENDIX 

1 . The method of obtaining information via the Internet from each of a plurality of 
diverse data resources having different characteristics in response to a request from a requesting 
application program which comprises, in combination, the steps of: 

storing a separate service description for each given data resource in a database, said 
service description including: 

an Internet address to which an output information request directed to said given 
data resource may be transmitted, 

a specification of the nature of input information to be supplied by said requesting 
application program, and 

a description of the nature of output information to be returned to said requesting 
application program in response to said output information request, 
establishing an application program interface for accepting service requests in standard 
form from said requesting application program, 

issuing a service request from said requesting application program to said application 
program interface, said service request identifying a particular resource, and 

executing a service interface program in response to said service request, said service 
interface program performing the steps of: 

obtaining the particular service description for said particular resource from said 
database, 

obtaining input information conforming to said specification contained in said 
particular service description from said requesting application program, 

producing an information request message that includes said input information, 

transmitting said information request message to the Internet address included in 
said particular service description thereby supplying said input information to said 
particular resource, and 

routing output information provided by said particular resource in response to said 
information request to said requesting application program. 
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2. The method as set forth in claim 1 wherein said step of storing a separate service 
description for each given data resource comprises registration means for accepting service 
description information in a predetermined format. 

3. The method as set forth in claim 2 wherein said predetermined format is the 
Extensible Markup Language. 

4. The method as set forth in claim 3 wherein said service description as expressed in 
Extensible Markup Language is validated against a Service Descriptor schema which specifies 
the content of said service description before said service description is stored in said database. 

5. The method as set forth in claim 1 wherein said service description as stored in said 
database further comprises contact information specifying a person or entity supplying the 
resource described in said service description. 

6. The method as set forth in claim 1 wherein said service description as stored in said 
database further comprises test information consisting of a fixed input value and a fixed output 
value which enables said service interface program to perform automatic testing of the described 
resource by sending said fixed input value to said resource and comparing the resulting output 
from said resource with said fixed output value. 

7. The method as set forth in claim 1 wherein said service description as stored in said 
database further comprises security information for ensuring that a request for output information 
originates from an authorized source before that request is satisfied. 
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8. Apparatus for processing a request for information from a specified resource which 
comprises, in combination, 

a database for storing a service description for each of a plurality of different resources, 
said service description comprising an input processing specification, an Internet resource 
address, and an output processing specification, 

an executing application program for issuing said request for information from said 
specified resource, and 

an interface program for receiving said request from said executing application program 
via a standard application program interface, said interface program including: 

means for retrieving the particular service description for said specified resource 

from said database, 

means for processing input data obtained from said executing application program 
in accordance with the input processing specification contained in said particular service 
description for said specified resource to produce a reformatted request, 

means for transmitting said reformatted request to the Internet resource address 
contained in said particular service description for said specified resource; 

means for receiving a raw response via the Internet from said specified resource 
in response to said reformatted request, 

means for processing said raw response in accordance with said output processing 
specification contained in said particular service description for said specified resource to 
produce a reformatted response, and 

means for transmitting said reformatted response to said executing application 
program. 
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9. Apparatus as set forth in claim 8 further including registration means for accepting 
descriptive data from a remote location and for processing said descriptive data to form said 
service description stored in said database. 

10. Apparatus as set forth in claim 9 wherein in said input processing specification 
includes the designation of an input adaptor program which, when executed, performs at least 
some of the processing of said request to produce said reformatted request. 

11. Apparatus as set forth in claim 10 wherein said output processing specification 
includes the designation of an output adaptor program which, when executed, performs at least 
some of the processing of said raw response to produce said reformatted response. 



IS 



PAGE 19/22 * RCVD AT 1013012006 9:02:17 PM [Eastern Standard Time] ' 8VR:USPTO-EFXRF-1/9 * DN1S:2738300 * CSID:1-508-629^540 CCALL * DUiWTION (m^pl^l 



To: USPTO * Page 20 of 22 



2006-10-31 02:02:30 (GMT) 



1 -508-629-6540 CCALL From: Charles Call 



12. The method of obtaining information via the Internet from each of a plurality of 
diverse data resources having different characteristics which comprises, in combination, the steps 
of: 

storing a separate service description for each given data resource in a database, said 
service description including: 

an Internet address to which an output information request directed to said given 
data resource may be transmitted, 

an input specification of the nature of input processing to be performed on each 
request before being supplied to said given data resource. 

an output specification of the nature of output processing to be performed on each 
response from a given data resource before that response is returned to a requesting 
application program, and 

establishing an application program interface for accepting service requests in standard 
form from executing application programs, 

receiving a service request identifying a particular resource from an executing application 
program via said application program interface and 

executing a service interface program in response to said service request, said service 
interface program performing the steps of: 

obtaining the particular service description for said particular resource from said 

database, 

processing said service request in accordance with said input specification 
contained in said particular service description to produce an output information request, 

transmitting said output information request to said Internet address specified in 
said particular service description, 

receiving raw output data in response to said output information request, 

processing said raw output data in accordance with said output specification to 
produce reformatted output information, and 

transmitting said reformatted output to said executing application program. 
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13. The method as set forth in claim 12 wherein said step of storing a separate service 
description or each given data resource comprises registration means for accepting service 
description information in a predetermined format. 

14. The method as set forth in claim 13 wherein said predetermined format is the 
Extensible Markup Language. 

13. The method as set forth in claim 14 wherein said service description as expressed in 
Extensible Markup Language is validated against a schema which specifies the content of said 
service description before each of said service descriptions is stored in said database. 

16. The method as set forth in claim 12 wherein said service description as stored in said 
database further comprises contact information specifying a person or entity supplying the 
resource described in said service description. 

17. The method as set forth in claim 12 wherein said service description as stored in said 
database further comprises test information consisting of at least one fixed input value and at 
least one fixed output value which enable said service interface program to perform automatic 
testing of the described resource by sending said fixed input value to said resource and 
comparing the resulting output from said resource with said fixed output value. 

18. The method as set forth in claim 12 wherein said service description as stored in said 
database further comprises security information for ensuring that a request for output information 
originates from an authorized source before that request is satisfied. 
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